Better Interdomain Path Diversity with BGP Path Splicing

Today’s interdomain routing protocol, Border Gateway Protocol (BGP) [9], scales well but suffers from two significant shortcomings. First, does not provide high availability in the event of failures or changes in network conditions (i.e., it converges slowly). Second, BGP is insecure: it provides little to no protection against malicious parties who can inject incorrect or misleading routing information into the global routing tables. Others have argued that multi-path routing can mitigate these problems, but designing a multipath routing protocol that offers a high degree of path diversity while still scaling well has proven difficult because routers must propagate multiple paths for each destination, both bigger routing tables, as well as more churn when network conditions change. However, BGP routing tables already store many routes to a single destination, which provides an opportunity for diversity without changing the routing protocol, if only end systems could somehow gain access to these alternate paths. This paper proposes a mechanism called BGP splicing, which simultaneously—and scalably—provides end systems access to multiple end-to-end BGP routes. Even though each BGP router selects only a single best route by default, each BGP-speaking router will typically have in its routing table a number of routes to every destination that is equal to the total number of iBGP and eBGP sessions. In BGP splicing, every border router in the AS installs every route in the routing table into the forwarding tables on the line cards. As in today’s routers, packets can still be forwarded along a default path, but extra bits in the packet header can cause the router to forward packets along a different path by using a different forwarding table entry. By installing alternate routes in the forwarding table and letting end hosts select among them, BGP splicing trades off more state in router forwarding tables for improved path diversity without introducing any additional protocol complexity. Although BGP splicing could be implemented at all BGP-speaking routers, autonomous systems (ASes) can gain most of the benefits of BGP splicing by deploying splicing at ingress points (whereby BGP splicing can allow end systems to control the path across an AS to a particular egress point) and egress points (whereby end systems can control the next-hop AS along a path to a destination) would be sufficient to achieve the benefits of BGP splicing. BGP splicing offers many potential benefits, including improved availability (through fast access to backup paths), better security (through the ability to simultaneously compare reachability on multiple paths), and higher throughput (through simultaneous access to multiple paths). Despite its conceptual appeal, BGP splicing faces many practical challenges. First, line cards must provide direct support for storing multiple routing table entries for a single destination, which not only requires more memory on line cards but also requires using a few extra bits for packet lookups, which might slow packet forwarding. Second, the BGP route selection process must be altered so that end hosts can use splicing bits to gain access to the best set of alternate paths that still comply with an AS’s policy. For example, a router should prefer all customer routes before all provider routes, and, among its set of most preferred routes, and, among the set of most preferred routes, it should rank routes so that spliced paths have high AS-level path diversity. Finally, because BGP splicing can deflect routing traffic onto a different “tree” at any ingress or egress router, it introduces the possibility of longer forwarding paths, and even forwarding loops. We present scenarios where splicing can introduce loops and mechanisms for detecting and preventing loops. The rest of this paper is organized as follows. Section 2 presents an overview of the general path splicing mechanism, and Section 3 explains path splicing as applied to BGP, highlighting in particular the differences between BGP splicing and path splicing, as well as the required router-level support for BGP path splicing. Section 4 presents safeguards against forwarding loops, Section 5 describes several possible applications of BGP path splicing, Section 6 summarizes related work, and Section 7 concludes.